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Be s chr e ibung 

System und Verfahren zur Obj ektidentif izierung in verteilten 
hierarchischen Systemen, insbesondere in Automatisierungssy- 
stemen 

Die Erfindung betrifft ein System und Verfahren zur Obj ekti- 
dentif izierung in verteilten hierarchischen Systemen, insbe- 
sondere in Automatisierungssystemen. 

Ein derartiges System und Verfahren kommt insbesondere im Be- 
reich der Automatisierungstechnik zum Einsatz. 

Der Erfindung liegt die Aufgabe zugrunde, eine Obj ektidenti- 
15 fizierung bei Operationen wie Verschieben, Kopieren, Umbenen- 
nen, etc. sicherzustellen . 

Diese Aufgabe wird durch ein System mit dem in Anspruch 1 an- 
gegebenen Merkmalen bzw. durch ein Verfahren mit den im An- 
20 spruch 2 angegebenen Merkmalen gelost. 

Der Erfindung liegt die Erkenntnis zugrunde, daS bisherige 
L5sungen eine geringe Stabilitat und/oder einen hohen Ande- 
rungsaufwand aufweisen. Es gibt zwei prinzipielle Identif i- 
kationsmechanismen, die eingesetzt werden (und auch miteinan- 
der kombiniert werden konnen) . Ein Verfahren beruht auf der 
Identif ikation von Objekten durch die Vergabe eines global 

eindeutigen Identif ikator3 fur jedoo Objekt. Mitt e ls diese s 

globalen Identif ikators ist sichergestellt , dafi ein Objekt 
3 0 unabhangig von seinem momentanen Auf enthaltsort wiederge- 

funden werden kann. Dieses Verfahren hat folgende Nachteile: 

• Zentrale Verwaltung: Das Verfahren benotigt zentrale Ver- 
wal tungs s t ruktur en wie eine Verwaltung der Objektidentif i- 
katoren und Umsetztabellen der Objektidentif ikatoren auf 

3 5 die Objekte. 

• Schlechte Unterstutzung von verteilten Arbeiten: Durch 
die Notwendigkeit einer zentralen Verwaltung wird das Auf- 
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teilen von Ob j ektmengen , deren getrennte Bearbeitung und 
anschliefcende Zusammenfiihrung (Stichwort Branch-and-Merge) 
erschwert . 

Beim zweiten Verfahren wird ein Objekt durch seine relative 
Lage zu einem anderen identif iziert . Dadurch ist dann auch 
festgelegt, wie das Objekt aufzufinden ist. Im gegensatz zum 
ersten Verfahren besitzt ein Objekt kein eindeutigen Identi- 
fikator, sondern dieser abhangig vom jeweiligen Ausgangsob- 
jekt, welches das andere ref erenziert . Dadurch ist keine 
zentrale Verwaltungs information notwendig. Jedoch ergeben 
sich folgende Nachteile: 

• Geringe Stabilitat : Durch Verwendung der relativen Lage 
zur Identifizierung wird der Identif ikator (bzw. die Iden- 
tif ikatoren) beim Verschieben des Objekts ungultig und das 
Objekt ist nicht mehr verfugbar (Broken Link) . 

• Holier Anderungsaufwand: Nach dem die Identif ikatoren 
eines Objekts ungultig geworden sind, miissen diese durch 
eine Art Korrekturlauf berichtigt werden. 

Bei der erf indunsgemaSen LSsung werden Kontexte zur Bildung 
mehrerer Indirektionsstuf en zur Verwaltung der Identif ikato- 
ren eingefiihrt. Dadurch ergeben sich effiziente Verfahren zur 
Reparatur von „Broken Links" ohne die Einfiihrung globaler, 
zentraler Verwaltungs funktionen . 

• Keine zentrale Verwaltung: Die Verwaltung erfolgt iiber die 
Kontexthierarchie. Das bedeutet, dafi jeder Kontext alle 
notwendigen Inf ormationen beinhaltet. 

. Untera li i tz un g von vertoiltom Arboiton: Di o Kontexthier a r- 
chie ist beliebig zerlegbar und wieder zusammenf ugbar . 
Dadurch ist ein Branch-and-Merge von Projekten problemlos 
durchf iihrbar . 

• Gerinaer Andungsauf wand : Durch die Kontexthierarchie ist 
unmittelbar klar, wo Anderungen von Identif ikatoren nach- 
zuvollziehen sirid. Die Anderungen sind auch nur an den be- 
troffenen Kontextobjekten durch zufahren. 
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Im folgenden wird die Erf indung anhand der in den Figuren 
dargestellten Ausfiihrungsbeispiele naher beschrieben und er- 
lautert . 



5 Es zeigen: 



FIG 1 ein Blockschaltbild zur Kennzeichnung des Sachver- 

halts: ein Client sieht Namen, ein Obj ektmodell ar- 
beitet mit Ids, 

10 FIG 2 eine schematische Darstellung fur die Vergabe und 

Zuordnung von Oj ektidentif izierungen als Objekt IDs 
und 

FIG 3 eine schematische Darstellung zum Verschieben eines 

Objekts mit der Bezeichnung „ES-Autol". 
15 

Im folgenden wird das Verfahren im Rahmen des OVA Engineering 
Objektmodells (OVA= Offene Verteilte Automatisierung) be- 
schrieben. Es ist jedoch auch fur andere Objektmodelle ein- 
setzbar. Fiir ein besseres Verstandnis der Zusammenhange soil 
2 0 im folgenden kurz auf den Kontext der Erf indung eingegangen 
werden : 



Fur jedes Objekt gilt, daS es eine Umgebung gibt, in der er 
bekannt ist. Bei OVA wird diese Umgebung durch den Kontext 
modelliert. Innerhalb eines Kontexts sind Namen und Identi- 
fikatoren aller enthaltenen Objekte bekannt und eindeutig. 
In der Regel ist der Kontext durch den Einstiegspunkt be- 
es timmt , — don e in Anw e nd e r zur Bearbeitung sei n e r Automat i . si , e- 
rungslosung wahlt. Kontext information ist an jedem Container- 
3 0 objekt (i.e. ein Objekt das andere Objekte enthalt) wie H- 

Container, Chart Oder Master verfiigbar. Die kleinste Umgebung 
fur einen Kontext ist jedoch ein Dokument . Fur den Fall ein- 
gebetteter Objekte wird die Kontextinf ormation des umgebenden 
Dokuments verwendet. Hieraus ergibt sich jedoch auch, daS 
3 5 Kontextinf ormationen hierarchisch gegliedert sein konnen. Da- 
bei sind tief erliegende Kontexte immer auch Teil des hierar- 
chisch hoheren Kontext. Daruber hinaus konnen weitere Kon- 
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texte, welche hierarchisch nicht verwandt sind, jedem belie- 
bigen Kontext assoziiert werden. Dann kann dieser Kontext auf 
die information des assoziierten Kontext zugreifen. Diese As- 
soziation ist jedoch unidirektional . Bei assoziierten Kon- 
texten sind automatisch auch die (hierarchisch) enthaltenen 
Kontexte assoziiert. 

Die Kontextinformation bestimmt, welche Objekte in dem Direc- 
tory eingetragen sind. Der Inhalt des Dokuments gehort auto- 
matisch zum selben Kontext; das gilt insbesondere auch fur 
gelinkte oder uber eine Kegel (.alia Objekte in diesem Ver- 
zeichnis", etc.) hinzugefiigte Objekte. 

Der Kontext ist auch der Verwalter der Kontext IDs. Diese 
werden spater beschrieben. 

Objekt identification 

Da OVA ein standardisiertes Verfahren verwendet urn auf die 
Datenhaltung zuzugreifen, ist es notwendig, die Objekte si- 
cher identifizierbar zu gestalten. Der Grund hierfur ist, da* 
ein Teil der Daten Strukturinf ormation ist, zum Beispiel wel- 
ches ES-Auto in welchem Chart liegt, oder welches Auto mit 
welchem verschaltet ist. Diese Strukturinf ormation unterliegt 
Regeln, die von der Implement ierung des Datenmodells beruck- 
sichtigt werden. Bei der derzeitigen Realisierung durch die 
Verwendung des IStorage Interface als Schnittstelle zur Da- 
tenhaltung, ist es immer moglich, diese Struktur zu andern, 
ohne das Datenmodell zu berucksichtigen . Zum Beispiel ist es 
einem Client moglich, Kopier- Verschiebungs- oder Umbenen- 

nun J ^ r ^-^^»n fiv^r Aa« T^foragp Interfax vorzunehmen, 

ohne dafi ein OVA Datenmodell- Server daran beteiligt ist. Das 
bringt das Problem mit sich, daS Inkonsistenzen entstehen 
konnen die spater von dem Anwender von Hand wieder richtig 
gestellt werden mussen. 

Daher sf lit sich nun die Frage, wie die Konsistenz so weit 
wie moglich hergestellt werden kann, ohne dem Entwickler von 
ES-Autos oder OVA Werkzeugen hierfur einen ubermaSigen Auf- 
wand abzuverlangen. Auch soli ten diese Mechanismen nicht an 
die Teile des API durchscheinen, die von den OVA Werkzeugen 
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verwendet werden. Eine Client-Anwendung sollte beispielsweise 
iirimer mit den ES-Auto Namen hantieren nicht mit kryptischen 
IDs (siehe FIG 1) . 

• Probl etma tlache Aktion&n 

Zuerst mussen die Aktionen beleuchtet werden, die potentielle 
Gefahren in sich bergen. Das sind zum einen alle unidirek- 
tionalen Beziehungen, und zum anderen Aktionen die an den Da- 
tenmodell-Servern „vorbeigehen tt . 

• Unidirektionale Links 
10 Unidirektionale Links sind problematisch, da es bei einer 

Aktion nicht ersichtlich ist, daS eine Inkonsistenz entsteht. 
Wird beispielsweise in einem Word-Dokument uber einen Link 
auf eine Datei verwiesen, und diese Datei zu einem spateren 
Zeitpunkt umbenannt, bekommt das Word-Dokument hiervon nichts 
15 mit und wird die Datei nicht wiederf inden . Dieses Problem 
kann nur durch eine Zentrale Instanz beseitigt werden, die 
wei£, wo die Datei zu f inden ist. 

• „Dumme w Aktionen 

Als dumme Aktionen werde hier Aktionen bezeichnet, die ohne 
2 0 das Wissen des Datenmodells ausgefiihrt werden. Als z.B. Umbe- 
nennen eines Objekts uber das IStorage Interface 
(istorage: : Rename Element ) . Solche Aktionen sind bei standardi- 
siertem Datenzugriff immer moglich. Auch hier konnte eine 
zentrale Instanz helfen, das Problem zu minimieren. Wichtig 
25 ist in beiden Fallen vor allem die Fehlererkennung, und wenn 
moglich auch eine Fehlerbehebung. 



• Object ZD Moniker 

Wie oben beschrieben, kann eine zentrale S telle die Objekte 
so verwalten, daS sie (nahezu) eindeutig identif izierbar 
30 sind. Daher werden alle Objekte uber Objekt IDs ref erenziert , 
die von der zentralen Stelle, in unserem Fall der Active 
Directory Service, aufgelost werden konnen. 

Diese ID ist von alien Aktionen unabhangig; sie wird bei der 
Objekterstellung vergeben und andert sich dann nicht mehr, 
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solange Kein anderes ObJeKt mit der selbsn ID existiert. Dies 
wird jedoch nur beim Kopieren auSerhalb das Datenmodells ge- 

schehen. 

jeder Container vergibt bei der Erstellung eines eingebette- 
ten Objektes einen Namen. 

FIG 2 zeigt eine schematische Darstellung fiir die Vergabe 
and Zuordnung von Oj ektidentif izierungen als Objekt Ids . Dxe- 
se IDs, in der Abbildung IDl, ID2. ID3 und ID4 sind D ewexls 
bei ihrem Container hinterlegt. Das heifct, der Hierarch.econ- 
tainer kennt IDl und ID2 , Chart 2 kennt ID3 . Diese IDs sind 
dabei nur innerhalb des Containers auf der obersten Ebene 
eindeutig. Das heiSt, Chart 1 kann auch wieder bei mit IDl 
anfangen. Nun k6nnen einzelne Objekte uber eine Kette von IDs 
identifiziert werden. ES-Auto 1 wird beispielsweise uber 
/IDl ! IDl identifiziert. Die Verschaltung von ES-Auto 2 zu ES- 
Auto 3 (IDy) erhalt folgende IDs : 

IDy = /IDl!ID4!c -> /ID2!ID3!d 

IDy ist nun eine Art Alias far die Verschaltung von ES-Auto 2 
nach ES-Auto 3 . Dieser wird bei dem hierarchisch niedrigst 
moglichen Container gespeichert. In diesem Falls ist das der 
H-Container 1, da sowohl Chart 1 als auch Chart 2 an der 
Verschaltung beteiligt sind. 

Bei der Verschaltung IDx sind nur die beiden ES-Autos 1 und 2 

b cU- iligt, dulu . iT kann d i n . Inf ormi H n n win TPv mifgelosf . 

wird, bei Chart 1 gespeichert werden. Dieses Vorgehen, die 
information so lokal wie moglich zu halten, hat den Vorteil, 
daS dieses Referenzen auch dann aufgelost werden konnen, wenn 
nur ein Teilkontext geoffnet wird. In so einem Teilkontext 
sind so alle Referenzen, Verschaltungen, etc. bekannt, die 
innerhalb des Kontextes bleiben. Alle Referenzen nach auSen 
(oder von auSen) kSnnen nicht aufgelost werden. 
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• Kontext IDs vs. lokale IDs 

Wie in dem obigen Beispiel zu sehen ist, gibt es zwei ver- 
schiedene Arten von IDs . Zum einen die lokalen IDs, wie zum 
Beispiel IDl, ID2 , . .., welche immer nur lokal dem Container 
5 bekannt sind. Zum anderen gibt es die Context- IDs , welche in- 
nerhalb des gesamten aktuellen Kontext ihre Gultigkeit besit- 
zen, Beide IDs miissen in ihrer Umgebung eindeutig sein. Die 
lokalen auf Containerebene, die Kontext-IDs kontextweit. 

• Auflosen 

10 Eine ID mute zum Beispiel aufgelost werden, wenn das Objekt 
^ aktiviert werden soil. So wird zum Beispiel ES-Auto 2 bei 
B einem Konsistenzcheck seine Verschaltungen priifen. Dazu muS 

IDx und IDy ermittelt werden. Urn dies zu tun, erfragt ES-Auto 
2 die einzelnen Objekte vom Kontext. Da die Veschaltungen als 
15 Moniker hinterlegt sind, genugt ein BindToObj ect ( ) aus Sicht 
des ES-Autos: 



MkParseDisplayName ( „@objectID ! IDy! Source* , &pMoniker) ; 
pConnector = pMoniker->BindToObject {); 

Da es sich bei den Monikern in diesem Fall um ObjectID Mo- 
niker handelt, wird der Server fur Ob j ect ID-Moniker , also der 
Kontext, nach dem Objekt gefragt. Dieser kennt IDy, da er fur 
seine Speicherung zustandig ist und lost ihn in seine Be- 
standteile auf. Die Funktion Pars e DisplayNomQ cxtrahiert IDy 
und Source und stellt fest, daS dies /IDl!ID4!c ist. Nun wer- 
den die Container rekursiv nach diesem Objekt befragt. 

Dieses etwas komplizierte Verfahren ist deshalb vorteilhaft, 
weil die (moglichen) Verschaltungen auch in den Teilkontexten 
zur Verfvigung stehen. In dem obigen Beispiel konnte auch 
Chart 1 als Einstiegspunkt (Kontext) gewahlt werden. Auf die 
35 Verschaltung IDx kann dann auch zugegriffen werden. IDy ist 
in diesem Falle eine externe Verschaltung, die solange nicht 
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zur Verfugung steht, wir sich der Bearbeiter nur in dem Kon- 
text von Chart 1 bewegt. 

• v&rwendung / Beiapielo 

Nun werden die Auswirkungen an einigen Beispielen gezeigt . 
Die Aktionen sind Verschieben, Kopieren, Loschen und Umbenen- 
nen. 

• Verschieben 

Ausgangssituation 1st Fehler. Verweiscjuelle konnte nicht 
gefunden werden. . Nun wird ES-Auto 1 von Chart 1 in Chart 2 
verschoben (siehe Fehlerl Verweisquelle konnte nicht gefunden 
werden.). Dies erfolgt auf 2 verschiedene Arten. Zum einen m 
einem OVA Werkzeug, zum anderen an dem Datenmodell vorbei 
("dummes Verschieben"). 

Verschieben im OVA Werkzeug 

Wird in einem OVA Werkzeug der verschiebungsvorgang ange- 
stolen, ubernehmen die Server des Datenraodells die Aktxon und 
sorgen somit dafur, daS alle Referenzen gal tig bleiben. Als 
Agitatoren sind hier die beiden Charts im Spiel. Im Source 
Chart wird die Methode MoveESAuto angesto&en. . Ihr wxrd das 
ES-Auto und der Ziel-Chart mitgegeben: 



pChartl->MoveESAuto (.ESAuto 1", P Chart2); 



in der Methode MoveESAuto sind nun alle notwendigen Schrxtte 
gekapselt. Das sind zuerst das kopieren des ES-Autos m Chart 
2 dann das Loschen des ursprunglichen Autos aus Chart 1 und 
zuletzt die Anpassung der IDs. Da sich bei einer solchen Ak- 
tion immer nur die IDs bis zu dem Objekt, an dem die Aktxon 
ausgefuhrt wurde, verandern konnen, muS auch nur dxes dem 
Kontext mitgeteilt werden: 
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pContext->UpdateRef erence ( „ ID1 ! ID1 * , „ ID2 ! ID4 " ) ; 



Diese Methode veranlaSt den Kontext, alle IDs, die mit 
5 „ID1!ID1 W beginnen, auf „ID2!ID4 tt zu andern. 

FIG 3 zeigt eine schematische Darstellung zum Verschieben 
eines Objekts mit der Bezeichnung ff ES-Autol tt . 

10 "Dummes" Verschieben 

Beim „dummen tt Kopieren sind die Server des Obj ektmodells 
nicht beteiligt. Daher kann der Update der IDs zu diesem 
Zeitpunkt auch nicht durchgefuhrt werden. Um eine solche Ak- 
tion auszuftihren genugt es, die persistente Datenablage von 
15 ES-Auto 1 aus der Ablage von Chart 1 in die von Chart 2 zu 

verschieben. Bei einem Offnen von Chart 1 wird dieser ES-Auto 
1 nicht mehr anzeigen und seinen Eintrag zu „ID1" loschen. 
Beim Offnen von Chart 2 wird dieser feststellen, daS ein ES- 
Auto in seiner Datenablage hinzugekommen ist, fur das noch 
20 keine ID vergeben ist. Daher wird ES-Auto 1 nun eine ID zuge- 
ordnet. Ferner mussen noch die Referenzen von ES-Auto 1 und 
den beteiligten Partnern ersetzt werden. Im Falle von bidi- 
rektionalen IDs ist dies kein Problem. Wird ES-Auto 1 nach 
seinen externen Referenzen gefragt, wird es IDx zuruckgeben. 
Wenn der Kontext nach dieser ID gefragt wird, kann er nur 
einen Teil („ID1!ID4 W ) unmittelbar auflosen. „ID1!ID1 U zeigt 
zu diesem Zeitpunkt noch ins Leere. Da die Aktion aber durch 
eine Ubcrprufung von ES - Auto 1 au s gelost wurd e , — k a nn d i es bft- 
hoben werden (evtl. nach Ruckfrage an den Benutzer) : 
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Foreach id In P ESAutol->GetExternalRef s () 
bOK = CheckReference (id. Source); 
if ! bOK 

UpdateReference (id. Source, „ID2!ID4"); 

Endif 

bOK = CheckReference ( id. Destination) ; 
if ! bOK 

UpdateReference (id. Destination, „ ID2 ! ID4 » ) ; 



Endif 



Endfor 



• Kopieren 
Auch beim Kopieren so 



lien beide Wege untersucht werden: 



Kopieren im OVA Werkzeug 

Wird ES-Auto 1 nur kopiert, ist an den Refernezen nxchts zu 
andern. Beim Ziel ES-Auto mu* Chart 2 eine neue ID vergeben 
(bspw. ID4) . Ferner sollten alle externen Referenzen des 
neuen ES-Autos gelSscht. 



"Dummes" Kopieren , n , 

Wird ES-Auto 1 wie beim Verschieben wiederum am Objektmodell 
vorbei kopiert, verweisen 2 ES-Autos auf ES-Auto 2 Dies ,st 
Jedoch kein Problem, da auch hier Chart 2 feststellt, daS ib. 

. , , t t g f (kejp^ ID) - Wie beim Ver- 
schieben, wird er nun eine neue ID vergeben und die externen 
Referenzen des ES-Autos testen. In diesem Falle exxstxert 
jedoch ES-Auto 1 auch in Chart 1. Daher wird dieser Check 
keinen Fehler zuruckgeben. Daher muS gepruft werden, ob das 
unbekannte ES-Auto Teil der externen Referenz ist. Der Code 
von oben muS also noch etwas erweitert werden: 
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Foreach id In pESAutol->GetExternalRef s () 
bOK = CheckReference (id. Source) ; 
If ! bOK 

5 UpdateReference (id. Source, „ID2!ID4 W ); 

else 

If ! IsReferenceParticipant ( # ID2!ID4 tt ) 

pESAutol->RemoveReference ( „ID2 !ID4") ; 

Endif 

10 Endif 

bOK = CheckReference ( id. Destination) ; 
if ! bOK 

UpdateReference (id. Destination, „ID2!ID4") ; 

else 

If ! IsReferenceParticipant („ID2!ID4") 

pESAutol->RemoveRef erence ( „ID2 ! ID4") ; 

Endif 

Endif 

Endf or 
• Loschen 

Beim Loschen eines ES-Autos fallen folgende Schritte an: 

Atf^^ Loschen im OVA Werkzeug 
^^Hb Wird das ES-Auto geloscht, konnen unmittelbar auch alle Refe- 
renzen geloscht werden. Dabei wird dem Kontext mitgeteilt, 

daS eine bestimmte ID nicht mehr gulf.i.g ist, Dieser kann nun 

alien (nach Benutzerruckf rage) Objekten, die eine Refernez uf 
diese ID haben, die Mitteilung weiterreichen, daS die ID un- 
30 giiltig ist. Wenn beispielsweise in Fehler! Verweisquelle 

konnte nicht gefunden werden. ES-Auto 1 geloscht wird, mufi 
folgender Code ausgefuhrt werden: 




15 
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RemoveReference („ID1!ID1") 



Dieser Aufruf hat zur Folge, daS der Kontext bei alien Part- 
nern die Methode RemoveExternalRef erence () aufruft. 

"Dummes" Loschen 

Beim dummen Loschen konnen zwei Situationen auftreten: ent- 
weder wird Chart 1 zuerst geoffnet. Dieser stellt fest, daS 
zu der ID1 kein ES-Auto mehr existiert. Er loscht nun seinen 
Eintrag „ID1". 

Andererseits kann ein Objekt versuchen, die Referenz auf zu- 
losen (z.b. ES-Auto 2). Da dies nicht moglich ist, wxrd der 
Benutzer gefragt, was mit ES-Auto 1 passiert ist, und was mxt 
der Referenz geschehen soil. 

• Umbenennen 

Umbenennen verhalt sich wie Verschieben. 

Zusammenfassend betrifft die Erfindung somit ein System und 
Verfahren zur Objektidentif izierung in verteilten hierarchi- 
schen Systemen, insbesondere in Automatisierungssystemen . Zur 
Sicherstellung einer Objektidentif izierung bei Operationen 
wie Verschieben, Kopieren, Umbenennen, etc. wird vorgeschla- 
gen, daS Kontexte zur Bildung mehrerer Indirektionsstuf en zur 
Verwaltung von Identif ikatoren eingefuhrt werden. Dadurch er- 
U uLu a c ich - f v-rfhr n n -nr Brp -. i~.1-nr von . sog^nannten 

„Broken Links- ohne die Einfahrung globaler, zentraler Ver- 
waltungsfunktionen. 
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Patentanspriiche 

1. System zur Objektidentif izierung in verteilten hierarchi- 
schen Systemen, insbesondere in Au toma t i s ierungs sy s t emen mit 
Mitteln zur Bildung mehrerer Indirektionsstuf en zur Verwal- 
tung von Identif ikatoren von Objekten. 

2. Verfahren zur Objektidentif izierung in verteilten hierar- 
chischen Systemen, insbesondere in Automatisierungssystemen, 
bei dem die Objekte durch mehrere Indirektionsstuf en zur Ver- 
waltung von Identif ikatoren identif iziert werden. 
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Zusammenf assung 



System und Verfahren zur Objektidentif izierung in verteilten 
hierarchischen Systemen, insbesondere in Automatisierungssy- 



stemen 



Die Erfindung betrifft ein System und Verfahren zur Objek- 
tidentif izierung in verteilten hierarchischen Systemen, ins- 
besondere in Automatisierungssystemen. Zur Sicherstellung ex- 
ner Objektidentif izierung bei Operationen wie Versch.eben 
Kopieren, Umbenennen, etc. wird vorgeschlagen, da* Kontexte 
zur Bildung mehrerer Indirektionsstuf en zur Verwaltung von 
Identifikatoren eingefuhrt werden. Dadurch ergeben sxch ef- 
fiziente Verfahren zur Reparatur von sogenannten „Broken 
Links" ohne die Einfuhrung globaler, zentraler Verwaltungs- 



funktionen. 



FIG 2 




Fig. 2 
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